In a traditionally known tracing approach used to analyze and identify the cause of a fault occurring in a program, the execution status of the program is output in chronological order to a standard output device such as a file. When trying to acquire more information using tracing, however, additional processing is required beyond processing of the original application logic to record the execution status of the program. This degrades performance. Furthermore, unless information is acquired within a suitable range, a large amount of data needs to be collected, which becomes burdensome to system resources.
Thus, the following measures are traditionally taken for the purpose of tracing in order to minimize the performance degradation and the burden to system resources. For example, it has been known to classify information to be collected according to its importance as specified by a user, in order to avoid acquisition of information with low importance. Alternatively, a tracing function may be provided for a particular thread to collect information only for processing executed on the particular thread.
Also known is the use of a debugging device which classifies threads as exclusive execution threads and other threads, and collects information while controlling the execution order of the threads to prevent the exclusive execution threads from being executed simultaneously. This improves debugging efficiency (see, for example, Japanese Published Unexamined Patent Application No. 11-338733). Also known is a technique in which a normal interpreter and an interpreter for tracing are provided and are switched for use in order to control executability of the tracing function (see, for example, Japanese Published Unexamined Patent Application No. 2002-55848.
According to these known techniques, however, the execution of a trace can be controlled only for predetermined threads and program portions identified in advance or according to settings or setting changes entered by a user before and during execution of the program. In other words, it is impossible to perform information collection suitable for the thread generation status that varies dynamically, in actual operation, in response to various kinds of execution requests. Accordingly, if one of the known tracing technique is used to analyze a fault which occurs only under a multithread environment, information is collected by a tracing process even for cases that do not correspond to the fault occurrence conditions. An example of this occurs when a program is executed in a single thread, and, as a result, the collected information includes a large amount of data which is not related to the cause of the fault occurrence. This large data set requires subsequent analysis, which is burdensome in itself.
In a multithread program, a fault caused by simultaneous execution of a particular process by multiple threads depends on timing considerations such as the processing status of each thread. Accordingly, it is difficult to identify the cause of the fault in comparison with a fault caused in a single thread.
Furthermore, when conventional tracing is used for analyzing a fault which occurs only in a multithread environment, the collected information includes a lot of data unrelated to the cause of the fault, thereby causing a lot of unproductive processing. Accordingly, in some cases, tracing may not be permitted in an actual operational environment.